Skip to main content

AREX Datasheet

The principle of AREX is to inject a designated Java process via the AREX Agent, and record the request/response as well as the request/response from the process to the outside during recording. Then, based on the TransactionID, these information will be stored in the database.

As shown in the above, when AREX replays, it retrieves the request from the database and replays it, with the specific steps as follows:

  1. The Schedule service sends a request to the service being tested, with the 'arex' included in the request header.
  2. The tested service has loaded the Agent, and will call the corresponding code after receiving the request. The replayID will be stored in the call stack.
  3. When the call chain accesses the MySQL database, the registered code will detect that it is in replay mode. At this point, the system will retrieve the previously recorded MySQL response data from the MongoDB database and return it to the function caller, instead of accessing the actual MySQL database.
  4. The same approach also applies to Redis requests. In addition, new versions of requests will also be recorded in the database.

AREX uses MongoDB as its database system, and many of its functionalities and logics are related to data tables. For example, the registration of the application, as well as the recording of requests and responses, are all stored in data tables. Additionally, information such as replay plans, replay results, and intermediate data are also stored in data tables. Due to the complexity of AREX's call chains and data read/write operations, users may encounter some unexpected issues during usage, such as registration failures or unsuccessful recordings. In such cases, the simplest and most direct solution is to check the data tables in order to understand the cause of the problem.

So, this article has compiled some of the data tables of AREX and their meanings for students who want to use them more deeply, in order to reduce some learning costs.

Below are the collection names and their related descriptions in the MongoDB database for AREX version 0.2.8 and above.

Collection NameUsageDescriptionvolume level
AppUsed to store the applications registered by AREX Agent.appid is the field displayed on the UI, and the field appName is not used and can be ignored. Checking skill: if a certain application is not displayed correctly on the UI, it can be queried in this table.10+
CaseSummaryUsed to store the cases of aggregating based on the classification of comparison differences.Used as an intermediate table for intelligent analysis of comparison results. The comparison differences are divided into major and minor categories, where major categories represent broader differences, while minor categories are more specific differences under major categories.20,000+
ConfigComparisonDecompressionUsed to store the configuration of field compression types in comparison settings.
ConfigComparisonExclusionsUsed to store the ignored nodes in the comparison settings.If configured, the ignored nodes will be skipped during the replay comparison. These nodes include data such as timestamps, random numbers, IPs, etc., which do not have significant impact on the comparison results.
ConfigComparisonInclusionsUsed to store the nodes to be compared in the comparison settings.
If configured, it represents that only the nodes in the table will be compared during the comparison. This function is opposite to ConfigComparisonExclusions. However, this table is not currently being used.
ConfigComparisonListSortUsed to store the fields used for sorting arrays during comparison in the comparison settings.
ConfigComparisonReferenceUsed to store the reference relationship between nodes in the comparison settings.
DynamicClassUsed to store the configuration for dynamic class.The dynamic class configuration in the user interface is obtained from this table.
EnvironmentEnvironment variable configuration tableTable of configured environment variables
FSFolderCollection——Folder tableA table of folders under a collection, similar to subsets in Postman.
FSInterfaceCollection——Interface request tableA table of API requests under a collection/folder.
FSCaseCollection——Case tableThe test case table under the interface request (FSCase is a sub-level of FSInterface), and the add field stores the HTTP method and URL of the test case.
FSTraceLogCollection logs of additions, deletions, and changesThis table is used to recover a Collection in case of accidental deletion or other mistakes during interface testing.
FSTreeCollection tree structure table, used with FSFolder, FSInterface, FSCase
InstancesList of services with the AREX Agent installed.The agent reports the machine status every 2 minutes, and the record has a TTL index of 3 minutes and will be deleted automatically when it times out. Checking technique: check for the currently active tested services (including the agent and have been started).
LabelCollection——Configuration Table of LableLabels set for test cases.
MessagePreprocessPre-processing table
PreprocessConfigPre-processing configuration table
RecordServiceConfigService recording configuration table
ReplayCompareResultTable that records the comparison details of each test case (including external calls)The columns baseMsg is compressed with zstd and need to be decompressed to view the plaintext. This table is used to view the comparison results of a test case. 400,000+
ReplayPlanReplay Report——Plan Table (generated by the Schedule service)appid is the name of the application as seen in the front-end page 700+
ReplayPlanItemReplay Report - Interface TableA list of all the accessed interfaces in the replay report, generated by the Schedule service. 13,000+
ReplayRunDetailsReplay DetailsGenerated by the Schedule service, with partial duplication in ReplayCompareResult.212,000+
ReplayScheduleConfigApplication replay configuration table
ReportDiffAggStatisticReplay report——Differences statistics table1900+
ReportPlanItemStatisticReplay report——Interface TableGenerated by the Report service12,000+
ReportPlanStatisticReplay report——Plan TableGenerated by the Report service
RollingConfigFileMockerRecorded case——Configuration tableConfiguration of recorded cases
RollingDatabaseMockerRecorded case——Database tableRecorded data in Database format.12,000+
RollingDubboConsumerMockerRecorded case——Dubbo Consumer tableRecorded data in Dobbo Consumer format.
RollingDubboProviderMockerRecorded case——Dubbo Provider tableRecorded data in Dobbo Provider format.
RollingDynamicClassMockerRecorded case——Dynamic class tableRecorded data in Dynamic class format.28,000+
RollingHttpClientMockerRecorded case——Http Client tableRecorded data in Http Client format.
RollingRedisMockerRecorded case——Redis tableRecorded data in Redis format.42,000+
RollingServletMockerRecorded case——Servlet tableRecorded data in Servlet format.21,000+
PinnedDatabaseMockerSaved case——Database tableDatabase format data saved from recorded cases, obtained from RollingDatabaseMocker after saving recorded test cases.
PinnedDynamicClassMockerSaved case——Dynamic Class tableDynamic Class format data saved from recorded cases.
PinnedHttpClientMockerSaved case——Http Client table
PinnedRedisMockerSaved case——Redis tableRedis format data saved from recorded cases.
PinnedServletMockerSaved case——Servlet tableServlet format data saved from recorded cases.
SceneInfoTable of scenarios aggregated according to the classification of comparison differences
ServiceApplication Services TableAREX creates a record for each application by default
ServiceOperationInterface table
Useruser table
UserWorkspaceUser-Workspace relationship table
logsSystem log table633,000+